home *** CD-ROM | disk | FTP | other *** search
/ Aminet 52 / Aminet 52 (2002)(GTI - Schatztruhe)[!][Dec 2002].iso / Aminet / comm / irc / epic4.lha / doc / DCC_REVERSE < prev    next >
Text File  |  2002-09-18  |  8KB  |  196 lines
  1. A treatise on DCC REVERSE
  2. Prepared on May 9, 2002
  3. $EPIC: DCC_REVERSE,v 1.4 2002/05/13 21:45:42 jnelson Exp $
  4. -------------------------------------------------------------------------------
  5.  
  6. Prologue
  7. --------
  8. All p2p (peer-to-peer) systems fundamentally revolve around two clients
  9. making a bi-lateral internet connection and swapping data across that 
  10. connection.  On a technical IP level, this requires that one of the peers
  11. act as a server and one of the peers acts as a client.  In this age the 
  12. proliferation of firewalls (both voluntary and involuntary) make it 
  13. more difficult to act as an internet server.
  14.  
  15. About DCC
  16. ---------
  17. DCC (Direct Client Connection) is the internet's oldest semi-anonymous
  18. p2p data transmission mechanism, dating back to 1991.  It is rooted in 
  19. and part of the IRC culture and so is widely available in IRC clients.  
  20. There are two applications of DCC: one is to exchange text messages 
  21. directly with another user (without sending them through normal IRC 
  22. channels), and the other is to share a file with another user.  The
  23. DCC specification limits conforming implementations to use IPv4 only.
  24.  
  25. The Problem
  26. -----------
  27. The construction of the DCC system requires that the peer who wishes to 
  28. share his file with another peer must have the ability to act as an 
  29. internet server.  Some users are unable to act as internet servers and 
  30. thus cannot share files via the DCC system.
  31.  
  32. A modest proposal
  33. -----------------
  34. It would be adventageous for a user who wishes to share a file with 
  35. another user to be able to do so without having the requirement of 
  36. being an internet server.  A user should be able to ask offer a file
  37. to another user coupled with a request for the other user to act as
  38. the server.  The direction of this connection is thus "reversed" where
  39. the reciever is the server and the sender is the client.
  40.  
  41.  
  42. STAGE ONE: The offer
  43. --------------------
  44. The sender may send to the reciever some such handshake:
  45.  
  46.     PRIVMSG reciever :^ADCC REVERSE <name> <size> <key>^A\r\n
  47.  
  48. Where the symbolic tags have the following meaning:
  49. <name>  - The name of the file with no directory components.
  50. <size>  - The size in full of the file.  Number is represented as ascii
  51.           digit characters.  The number may be a 64 bit integer.
  52. <key>   - A string containing random characters with ascii values 33 to 
  53.           126 inclusive chosen by the sender.  The <key> may be from 1
  54.           to 50 characters in length, but 12 is probably a good size.
  55.       The purpose of this key is to act as a unique identification
  56.       mark for the transaction and to authenticate the legitimacy
  57.       of an assent from the other peer.  The client should avoid 
  58.       using duplicate keys.
  59.  
  60. STAGE TWO: The response
  61. -----------------------
  62. If the recipient wishes to reject the offer he may send an affirmative
  63. cancellation of the offer by a *CTCP REPLY*:
  64.  
  65.     NOTICE sender :^ADCC REJECT REVERSE <key>^A\r\n
  66.  
  67. If the recipient wishes to indicate his assent to the transfer, he may
  68. do so by sending back a *CTCP REPLY*:
  69.  
  70.     NOTICE sender :^ADCC REVERSE <key> <start> <p-addr> <port>^A\r\n
  71.  
  72. Where the symbolic tags have the following meaning:
  73. <key>    - The exact same <key> as passed in the original handshake.
  74.        Please see notes on "Unrequested reverse transfers" below.
  75. <start>  - The number of characters at the beginning of the file that the
  76.        reciever wishes the sender to skip.  This permits a "restart" of
  77.        a previously canceled transfer from the place the transfer was lost.
  78.            Ordinarily, this value would be 0 to recieve the entire file.
  79. <p-addr> - A "presentation address" representing the reciepient's IP address;
  80.            either a dotted-quad string for IPv4 (A.B.C.D), or a colon-separated
  81.        string for IPv6 (A::B::C).
  82. <port>   - The port where the reciepient is listening for a connection.  This
  83.        must be as ascii digits, in host order ("human readable").
  84.  
  85. Please see APPENDIX 1 for information how to parse this data.
  86.  
  87. STAGE THREE: The connection
  88. ---------------------------
  89. It is acceptable for the sender's client to immediately begin the transmission
  90. upon the receipt of any legitimite assent.  It is acceptable for the sender's
  91. client to require the sender to affirmatively begin the transmission.  In 
  92. either case, the sender is permitted the privelege of revoking the offer 
  93. by sending an affirmative cancellation of the offer by a *CTCP REPLY*:
  94.  
  95.     NOTICE reciever :^ADCC REJECT REVERSE <key>^A\r\n
  96.  
  97. If the sender has not revoked the offer, the sender's client is to connect
  98. to the recipient's client using the address and port given by the DCC REVERSE
  99. reply.  If the connection cannot be established, the sender's client may send
  100. an affirmative cancellation to the sender in the manner described above.
  101.  
  102. Once the connection has been successfully established, the transmission
  103. shall continue as though the connection had been established via DCC SEND.
  104.  
  105.  
  106. UNREQUESTED REVERSE TRANSFERS: [WORK IN PROGRESS]
  107. -------------------------------------------------
  108. There may be circumstances where it is more convenient for a reciever to
  109. ask for a specific file from a sender than it is to wait for the sender
  110. to extend an offer to transmit.  An "unrequested reverse transfer" is 
  111. a request by a receiver to be sent a file without having received an 
  112. invitation.  A reciever may make an unrequested reverse transfer by sending
  113. a *CTCP REPLY*:
  114.  
  115.     NOTICE sender :^ADCC REVERSE <key> <start> <p-addr> <port>^A\r\n
  116.  
  117. Where the symbolic tags have the same meanings as in STAGE TWO, except that
  118. <key> shall be made up by the the reciepient. [PROBLEM] There is no way to
  119. identify the file you want.  Should DCC REVERSE assents be extended to 
  120. include the filename, or should unrequested reverse transfers not be accepted?
  121. Even if we did include the filename, how would you map that to a file on
  122. the local filesystem?  There could be many such filenames present [PROBLEM]
  123.  
  124. It would be unwise for a client to automatically accept unrequested reverse
  125. transfers because malicious users could transfer sensitive data from the
  126. receiver's machine without their affirmative consent.
  127.  
  128. Notwithstanding this, a client may choose to present an unrequested reverse
  129. transfer to the user for their assent.  If the user assents to the transfer,
  130. the connection shall proceed directly to STAGE THREE.
  131.  
  132. Unrequested reverse transfers might be useful for clients to automatically
  133. requested that a transmission that failed to complete be restarted.
  134.  
  135. Clients are under no obligation to accept or present unrequested reverse 
  136. transfers or to their user.  They may silently ignore them.  Sending back
  137. a DCC REJECT is not encouraged unless it is rate-throttled, to prevent
  138. floodnet attacks.
  139.  
  140. APPENDIX 1: PARSING DCC REVERSE HANDSHAKES
  141. ------------------------------------------
  142. The DCC REVERSE affirmation has the following form:
  143.  
  144.     NOTICE sender :^ADCC REVERSE <key> <start> <p-addr> <port>^A\r\n
  145.  
  146. You may save the <p-addr> and <port> data by using the following code:
  147. (This code is placed into the public domain and may be used for any purpose)
  148.  
  149.     int retcode;
  150.     struct addrinfo hints;
  151.     struct addrinfo *ai;
  152.     struct sockaddr_storage ss;
  153.     int sslen;
  154.  
  155.     /* AI_NUMERICHOST means that we are giving it a p-addr */
  156.     /* PF_UNSPEC means we don't care if it's IPv4 or IPv6 */
  157.     memset(&hints, 0, sizeof(hints));
  158.     hints.ai_flags = AI_NUMERICHOST;
  159.     hints.ai_family = PF_UNSPEC;
  160.     hints.ai_socktype = SOCK_STREAM;
  161.     hints.ai_protocol = 0;
  162.  
  163.     if ((retval = getaddrinfo(p_addr, port, &hints, &ai))) {
  164.         /* Error is in gai_strerror(error) */
  165.     }
  166.  
  167.     /* 
  168.      * Save the (struct sockaddr *) by copying it into a 
  169.      * (struct sockaddr_storage), which we will use later in connect().
  170.      * And no, I don't believe in using memcpy() for this.
  171.      */
  172.     ss = *(struct sockaddr_storage *)ai->ai_addr;
  173.  
  174.     /*
  175.      * connect() double checks to make sure that the address family 
  176.      * in the sockaddr agrees with this length.  Save this value or
  177.      * otherwise we'll have to figure out again later.
  178.      */
  179.     sslen = ai->ai_addrlen;
  180.  
  181.     freeaddrinfo(ai);
  182.  
  183. You may then later go back and connect to the receiver with:
  184.  
  185.     struct sockaddr *sa;
  186.  
  187.     sa = (struct sockaddr *)&ss;
  188.     if ((fd = socket(sa->sa_family, SOCK_STREAM, 0))) {
  189.         /* Socket failed */
  190.     }
  191.     if (connect(fd, sa, sslen)) {
  192.         /* Connect failed */
  193.     }
  194.  
  195. #End of document
  196.